…(cherry-pick argoproj#16016 for 3.7) (argoproj#16242)

Signed-off-by: Ali <alliasgher123@gmail.com>
Signed-off-by: Alan Clucas <alan@clucas.org>
Co-authored-by: Ali Asghar <98263017+alliasgher@users.noreply.github.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

…goproj#16088 for 3.7) (argoproj#16248)

Signed-off-by: isubasinghe <isitha@pipekit.io>
Signed-off-by: Alan Clucas <alan@clucas.org>
Co-authored-by: Isitha Subasinghe <isitha@pipekit.io>

…rry-pick argoproj#16102 for 3.7) (argoproj#16250)

Signed-off-by: isubasinghe <isitha@pipekit.io>
Signed-off-by: Alan Clucas <alan@clucas.org>
Co-authored-by: Isitha Subasinghe <isitha@pipekit.io>

…rgoproj#16160 for 3.7) (argoproj#16254)

Signed-off-by: isubasinghe <isitha@pipekit.io>
Signed-off-by: Alan Clucas <alan@clucas.org>
Co-authored-by: Isitha Subasinghe <isitha@pipekit.io>

ArtifactGC is on the allow-list of WorkflowSpec fields a user may set when
submitting via workflowTemplateRef under Strict/Secure mode, so that its
benign fields (Strategy, ForceFinalizerRemoval) work. However the struct
nests ServiceAccountName, PodSpecPatch and PodMetadata, which are applied
directly to the artifact-GC Pod. A user with create Workflow permission
could therefore set spec.artifactGC.serviceAccountName / podSpecPatch /
podMetadata to run the GC Pod with an arbitrary service account and pod
spec, escaping a hardened WorkflowTemplate. This is the same privilege
escalation class as CVE-2026-31892 / CVE-2026-42296 (GHSA-3775-99mw-8rp4),
reachable one level down through the allow-listed ArtifactGC field.

Reject these nested fields in ValidateUserOverrides and strip them (on a
copy, leaving the caller's spec unmutated) in SanitizeUserWorkflowSpec,
while preserving the benign ArtifactGC fields.


(cherry picked from commit 08763d1c380ae6995e011bd4633e66a7f21f3c3d)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>